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System and Method for Cross-Platform 
Update Propagation 

Cross Reference to Related Applications 

5 This application claims priority to provisional application no. 60/262,050, 

entitled "A Method and an Apparatus for Cross DB Update Propagation,** filed on 
January 16, 2001. 

Field Of the Invention 

The present invention relates to Enterprise systems that have front-end and 
10 backend data repositories that require updating. More specifically, the present 
invention relates to Enterprise systems that have front-end and backend data 
repositories that require the propagation of cross platform updates. 

Background of the Invention 

The wide use of the Internet has provided a new mode of business which has 

15 been frequently referred to as "e-Business" or "e-Commerce." The heart of eBusiness 
is the ability of system users, which at times are customers to be able to perform a 
variety of transactions using a web browser or other device that allows them to 
connect to the Internet. In the context of an "Enterprise,*' "Enterprise Data" may now 
be accessed and updated by customers in a much less controlled environment. In 

20 Enterprises that are engaged in eBusiness where, in fact, customers do have such 

access, there is a trend to isolate the critical backend data repositories from the front- 
end data repositories. This is felt necessary to prevent the backend data repositories 
from being manipulated by customers through web browsers. Further, the front-end 
and backend data repositories may be different types of systems running different 

25 types of database software. For example, the front-end repositories may be S/390 
systems from IBM running Database2 software from IBM, Inc., while the backend 
data repositories may Unix/NT based systems from Sun Microsystem Inc/Microsoft, 
Inc. running Oracle database software. 

Given that front-end and backend data repositories are all part of the same 

30 Enterprise system, it is very likely that some of the updates to the backend data 

repositories will propagate to the front-end data repositories and vice-versa. In order 




PCT/DS02/01429 



1 



WO 02/057957 

PCT/DS02/01429 

to carryout such cross-platform updates, nonnally, there is very specialized software 
components added to the respective platform software to effect the desired update 
propagation. Generally, platform-to-platform propagation using this software is 
carried out using the system's Transport Control Protocol^nterrace Protocol 
5 ("TCP/IP") communications lines. 

The add-on software components are expensive to the system in a variety of 
ways. These expenses include the amount of CPU cycles needed from both the front- 
end and backend servers, the loading of the TCP/DP communications lines, and there 
must be specially developed software for each specific enterprise logic. This latter 
10 requirement also means that additional supporting cross-system locking ri^hanisms 
and logic must be developed. As can be suspected, wim the need to handle these 
issues there is a strong likelihood that applicators developed m this enviro 
have bugs and be susceptible to various types of ftrilures. 

As an example, in any two platform system, which includes Enterprise 
15 systems with front-end and backend data repositories, there can be real-time 
consistent update propagation by including transaction application logic to the 
respective database servers. In the case of the cross platform propagation of updates, 
one of the transaction applications will be the source transaction application and the 
other will be the destination transaction application. Each of the transaction 
20 application is capable of serving as a source or destination transaction application. 
Therefore, each is developed so that it is capable of propagating updates that it 
intercepts to a program location at the destination database of the other platform The 
program at the destination database will acquire and retain the appropriate records 
relating to the updates propagated to the destination database. The destination 
25 database will then apply the updates to the destination database. 

After the successful update of the destination database, the destination 
program will transmit a "successful completion status" message to the source 
transaction application. This message will then permit the sources transaction 
application to complete its internal processing for the propagation. The system that 
30 has just been described, however, uses the respective server CPU cycle times and 
loads the TCP/TP communications lines to effect update propagation which is 
undesirable. 
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There is a need for a system and method the will more efficiently and 
effectively perform cross-platform update propagation without the problems and 
expense found in prior systems. 

Summary of the Invention 

5 The system and method of the present invention will effect the efficient and 

effective cross-platform updating of databases which is not application dependent. 
The system and method of the present invention do not require additional cross- 
system locking mechanisms, uses a very limited number of server CPU cycles, and do 
not use the TCP/IP communications lines. 

10 The system and method of the present invention may be carried out by updates 

for the respective databases being intercepted as reflected in thek^ 
logs. The intercepted updates are then applied to the databases by directly writing 
them to the appropriate database disks. According to the present invention, the 
interception of the updates and the writing of them to the disks are carried out using 

15 the I/O streams, thereby bypassing the need to use the respective different server 

CPUs and the TCP/IP communications lines. As an example, the I/O streams include 
Enterprise System Connection ("ESCON"), Small Computer System Interface 
("SCSrO, or Fibre Channel streams. 

An object of the present invention is to provide a system and method to 

20 effectively and efficiently propagate cross-platform updates between two discrete 
databases systems. 

Another object of the present invention is to provide a system and method that 
will effect cross-platform update propagation without the need to use platform server 
resources or TCP/IP communication lines. 
25 A further object of the present invention is to provide a system and method 

that will effect the propagation of cross-platform updates between two discrete 
database systems at the I/O streams associated with a system that may include the two 
discrete database systems. 

These and other objects will be explained in greater detail in the remainder of 
30 the specification, and in light of the drawings and the appended claims. 
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Brief Description of the Drawings 

Figure 1 shows a representative system faco^iating the system aM method 
of the present invention. 

Figure 2 shows a detailed representative view of a splitter that is used in 
implementing the present invention. 

Figure 3 shows detailed view of the common I/O buffer that is an element of 
the representative splitter shown in Figure 2. 

Detailed Description of the Invention 

The system and method of the present invention are directed to the 
propagation of cress-platfonn updates of databases^ for exanmle, an Enterprise 
system Given that these platforms may be operating usmg diflerem o 
and database software, the present ^ mver^n is not apphcation dependent The pre^ 
invention effects the cross-platform propagation of updates through the use of I/O 
streams. Accordingly, the system and method of the present invention do not use 
valuable and expensive CPU cycles nor excessively load the TCP/TP communication 
lines to perform the desired cross-platform propagation of updates. 

An overview of the system and method of the present invention is that when 
there is a system, such as an Enterprise system with at feast two platforms, in which 
cross-platform database updating is desired, the specific updates for the database(s) of 
a particular platform is intercepted by a system element added for that purpose. The 
intercepted update information is then written to the log of the original database the 
source database, to which the update was intended and to the log of the database for 
the other platform(s), the target database^. The updates are then written to the source 
and target databases in a manner that does not interfere with other activity of the 
25 system. 

The present invention may be implemented at least in part through a platform 
that is described in commonly assigned, co-pending U.S. patent application Serial no. 
09/605,438, titled "Device, System, and Method of Intelligently Splitting Information 
in an I/O System.- This application is incorporated herein by reference. 

Before describing the system and method of the present invention in greater 
detail, there are certain terms that will be used m the description that will have the 
following definitions: 
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Notations 





I Joe identification of a source database record Rj. 




The identification of a target database record 15. 




An entry in the source database log indicating the update of record 
R4 by. the transaction identified as k. 




An entry in the target database log indicating the update of record rj 
by the transaction identified as k. 



Database Transactions 



T (Rj, % Rfo Read (Ri, R*, Ro)) 



Source database records Ri, Rj, and ft* are updated 
based on the values of source records Ri, Rm, R^, 
and R<>. Therefore, each transaction T has a read 
domain R» records Rii R,n, Rn, Ro, and an update 
domain U, records Rj, Rj, R^. 



5 Parallel Transactions : Transactions Ti and Tj are parallel if oite bf the following is 
true: 



1. 


Ti starts after Tj starts but before Tj aids. 


2. 


Tj starts after Ti starts but before Ti ends. 


3. 


Ti starts before Tj starts and raids after Tj ends. 


4. 


Tj starts before Ti starts and ends after Ti ends. 



Atomic Tr ansactions : A transaction T=(R» U) is atomic if for any other parallel 
transaction Ti==(Ri, UO, the foflowing is true: 



1. 



There are less than 2 records in (R u U) n U { . This also may be stated as the 
operation 0((R u U) n U0<2 (the "atomicity equation"). That is, the transaction Ti 
cannot change more than one record in either the read or write domain of transaction 
T. 



If 0((R uU)n U0>1, then all read/update operations which violate 0((R u U) n 
UQ<2, occurred either before T started or after T ended. 



Update Propagation: For the purposes of cross-platform propagation the following 
applies: 



DB1 and DB2 are two independent database servers running on different systems. 

DB1 is the source database where the updates originate and DB2 is the target 
database where the updates will 1 



1 propagate. 



Ri may be a record that in DB 1 and n is a corresponding record based on predefined 
mapping in DB2. 



T (Rj, Rj, Rk, Read (Ri, Rm, R^, R«)) is a transaction executed by the source database, 
then following transaction execution, and after applying the update propagation 
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records r u rj , and ik, which correspond to % R*, will have the same values as R, 



Consistent Update Propagation : This is an update that complies with the following 
roles: 



1. 



Target database transaction atomicity is not violated. That is, updating r„r and rv ~ 
with values of Ri, % and R* does not violate the atomicity rules for any of the 
transactions executed natively by DB2, the target database, in parallel to the update 
propagation. F 



The atomicity of the transaction represented by the update propagation is not 
violated by any DB2, the target database, native transaction. 



10 



15 



25 



According to consistent update propagation definition, for any target transaction, 
Tj=(Rj, UO; and for any source update propagation transaction, T=(U), O ((R o TJ) n 
U0<2. This shows that an update propagation transaction on the target database DB2 
consists only of the update domain, since the update is not dependent on any target 
database DB2 values. Thus, for update propagation transactions, R=0. 
Real-Time Update. Prop agation: An update propagation that completes execution 
together with the original transaction that initiated the update propagation. 
Database T^ g: A set of primary and secondary log files consisting of log records that 
record all changes to a database. The database log is used to roll back changes for 
transactions that are not committed and to recover a database to a consistent state. 

Figure 1, generally at 100, shows a representative system that incorporates the 
system and method of the present invention. The system includes mainframe 
computer 102 that has a database management system ("DBMS") associated with it 
The DBMS will control the database system associated with the mainframe. As an 
example, for mainfram e computer could be an IBM S/390 system 
20 The mainframe control unit and database disks are shown at 104. The 

mainframe and DBMS at 102 connect to mainframe control unit and database disks at 
104 so that information data can be retrieved from, or added to the database disks. 
The DBMS and database may operate according to Database2 operating software 
from IBM. 

Again referring to Figure 1, system 100 also has open system server 106 that 
includes a DBMS that is used for controlling the associated database system that is 
shown at 108. The open system server may be a SAN/Solaris server. The DBMS and 
the database may be an Oracle DBMS and Oracle disks, respectively. 
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Host 1 10 is the system 100 element through which mainframe/DBMS 102 
connect to mainframe control unit/database disks 104, and open system server/DBMS 
connects to open server disks 108. Host 1 10 includes intelligent splitter 112 that 
connects mainframe/DBMS 102 connect to mainframe control unit/database disks 
5 104. Rather, host 1 10 has interface 1 14 that connects open system servei/DBMS 106 
to open system database disks 108. Host 1 10 also provides connectivity between 
splitter 112 and interface 114 so that propagation in accordance with the present 
invention can take place. 

According to Figure 1, host 110 uses one port of splitter 112 to handle 

10 ESCON connectivity 1 16 to mainframe/DBMS 102 and second port to handle 

ESCON connectivity 1 18 to mainframe control unit/database disks 104. Host 1 10 also 
supports interface 114, which may be a fibre channel interface card. Fibre channel 
interface card 114 handles connectivity 120 to open system server/DBMS 106 and 
connectivity 122 to open system database disks 108. 

15 The system and method of the present invention may be implemented in a 

system such as is shown in Figure 1. In such a system, all **writes" to the logs of the 
source and target databases, and all "reads" to the target database are intercepted. The 
interception of this information or data takes place in the I/O streams. According to 
aspects of the present invention, host 110 may be programmed to direct splitter 112 to 

20 intercept all write commands in the I/O stream from mainframe/DBMS 102 and reads 
from the I/O stream from open system disks 108 as controlled by the open system 
server/DBMS 106. 

The I/O intercepts and I/O based activity with regard to the present invention 
will be performed at host 110 and splitter 112 according in commonly assigned, co- 
25 pending U.S. patent application Serial No. 09/605,493, titled "I/O System Supporting 
Extended Functions and Methods Thereof, " the contents of which is incorporated by 
reference. 

A detailed, representative view of splitter 112 is shown in Figure 2, generally 
at 200. In Figure 2, splitter 1 12 includes Port A, Port B, common I/O buffer 220, local 
30 processor 230, local processor memory 240, and communications bus 250. Ports A 

and B communicate with external connections 210A and 210B to receive and transmit 
data, for exanqrfe, according to ESCON protocol. Each of the Ports also 
communicates with common I/O buffer 220 using bus 214. It is understood that each 
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of the Ports has the capability of read visibility into the entire buffer and write 
visibility to specific buffer areas associated with the Port. 

^^»1/Obui&r220isu^to^ 
It will also contain frames created by local processor 230. It is from I/O buffer 220 
> that update data is intercepted and inspected. 

Local processor 230 runs software in n«nH>ry 240 to control splitter 112. For 
-ample, local processor 230 may run software that can read and/or write states to the 
Ports to control operation. Further, since local processor 230 can communicate with 
common I/O buffer 220, programs may be run to read and/or write information to 

I/O streams. 

V 

^^250isastrfforcomin^^ 
buffer 220, Port A, Port B, and processor memory 240. This bus win permit interrupt, 
command, address, and data information to be passed among the components 
connected to bus 250. That is, bus 250 facilitates communications to the uniquely ' 
addressed components connected to it 

Figure 3, generally at 300, shows splitter 112 that is shown in Figure 2 with 
commonl/O buffer 220 ^.^do^fc^*^^ 
address space of common I/O buffer 220 is subdivided so that each of the Ports and 

™*™°"^^^*^^^sp™. Forexample, common 
buffer 220 may be logically divided into three equal size, non^verlapping, memory 
segments 220A, 220B, and 220C. Port A may be associated with segment 220A, Port 
B with segment 220 B, and processor 230 with segment 220C. This is only meant to 
be representative and other configurations of the I/O buffer are possible and still be 
within the scope of the present invention. 

Again referring to Figure 1 , there are two databases systems shown. The first 
* shown as mainframe control unit/database 104 and the second as open system 
d-abase 108. As described, each may be running on different software. For example, 
-anoframe control unit/database 104 may be running Database2 software, while open 
system database 108 .nay be running an entirely different type of database software 
such as Oracle database software. For purposes of description only, mainframe ' 
contmlunitydataba^l^will be referred to as DB1, tfre source database, wh^re the 
updates originate, and open system database 108 will be referred to as DB2, the target 
database, where the updates are to propagate. 
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DB1 and DB2 each have a database log associated with iL These data 
structures are used in implementing the present invention. Among other things, the 
DB1 source database log and DB2 target database log contain records fiir all update 
transactions and their associated records. For example, for update transaction i, Ti= 
5 Update (Ri>Rj,Rk, Read (Rj, R^, R«, Ro)), the following data would be recorded in the 
database log: BTi, the begin transaction; the list of updated records with the updated 
new values, Ru = Vi, Rm> = Vj Rkji, = V*; and ETi, the end transaction. 

Many transactions will be occurring concurrently and, as such, the recorded 
sequences of the multiple transactions will interleave. Therefore, if Ti is being 
10 executed and concurrently Transaction j is being executed, T,= Update (R*i, %, R^, 
Read (Rn, Rmi, Rni, Roi)), then the recorded sequence in the database log may appear 
as the following: 

L= {BT i ,R M = Vi,R M = V j ,BT j ,Ra4=Vu, Rk* = V* = V jlf 
^ ETuRjij^VjnRu^V^BTj} 

The system and method of the present inventioii, which carries out update 
propagation, preferably, includes four components. These con^x>nents are source log 
processing, target log processing, update preprocessing, and update propagation to the 
target database. Source log processing creates the update domain for the update 

20 propagation transaction. Target log processing creates the update domain for the 
target transactions based on which transactions have to be rolled back before the 
update transaction starts. Update processing involves the destaging from the cache 
memory all of the records in the update domain of the update propagation transaction 
and roll back all pending target transactions that overlap the domain. Update 

25 propagation to the target database involves setting the time for X, the maxi^m time 
for reads, to ensure that the target transactions atomicity is not violated in the "unsafe 
zone" of transaction duration and propagate the update to the target database and its 
log. 

In order for the system and method of the present invention to operate 
30 properly, it is understood that reads and writes to storage in the source database and 
target database are intercepted in an I/O buffer, such as common I/O buffer 220 
shown in Figures 2 an 3. Common I/O buffer 230 will contain the data of the read and 
write operations, and the disk addresses to and from where the data was read or 
written. The update domains U of the update propagation T = (U) are obtained by 
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intercepting writes to the source database log. Similarly, the update domain U, for the 
target transaction T| is derived by intercepting all writes to die target database log. 

The interception and extraction of reads (or R,) is more involved given that the 
read operations do not appear in the target database log. When read operations are 
intercepted as they are executed directly to the database, there is no information that is 
leadfly available to indicate the transaction to winch it belongs. Since this information 
is not available, there can be no determination whether a particular read operation 
violated the atomicity equation. More specifically, a read operation cannot be 
associated with any other read or write operation m tl« same trausaction. 

According to the system and method ofthe present invention, each read 
operation is assigned a maximum time limit X. This win mean tl,at no read tran^ 
may take longer than X to complete. X may be set to any value but preferably it wfli be 
in milliseconds from predetermined events. The exact value of X may, however, 
depends on the particular application in which it is used. For example, X may equal to 
15 300ms in the Database2 update application. 

When considering read operations in the context ofthe present invention, V 
will belong to the transaction of some other read or update operation, if that other read 
or update operation occurred within the same time interval X relative to "r. " This 
applies to situations in the past and in the future relative to X. 

In light of read operations only being able to execute to locations, such as 
cache memory, there is not the possibility to intercept them and they are unnoticeable 
The present invention overcomes this problem by flashing the read information from 
the cache and invalidating in the cache any record that belongs to the update domain 
ofthe update propagation transaction. This is realized when there is a start of the 
execution of an update propagation transaction T and there is the ability to track all of 
the target reads to the relevant records. Even using this process, it is possible to miss 
some ofthe relevant reads to relevant records before T started. This is consistent with 
the definitions set forth above relating to parallel transactions and atomicity since it 
could have happened before the start of T. 

Referring the parallel transaction and atomicity definitions for this purpose it 
is understood that based on these definition reads can only execute to a separate stored 
location such as a cache. It is done this way according to the present invention 
because to the second condition of the atomicity definition, namely, if 0((R u U) n 
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Ut>l, provides that all read/update operations which violate O ((R uU)n U0<2, 
occur either before T started or after T ended, then at least one read or update 
operation wffl have occur after T has started. As such, it is necessary only to track of 
relevant read and update records from the time T started for the interval A, or ui^ 
ends, which ever occurs last. What then remains is to corrgiensate for the particular 
missing read operations, if they exist, that occurred before T started by setting the 
atomicity equation to 0((Ri u UO n U)>0. 

According to the system and method of the present invention, all parallel 
target transactions Ti arc rolled back to the update propagation transaction T for which 
0((Ri uUOn U)X>. This will take place even before the transaction f starts 
executing. These same transactions may also be rolled back after update propagation 
transaction T starts. However, under these conditions, it is necessary to ensure that the 
atomicity rules are not violated. 

The conditions under which the atomicity rule are not violated when the 
rollback takes place after update propagation transaction T has started executing is 
when the rollback process seeks to update one of the records in the update domain of 
transaction T and this record has already been updated by update propagation 
transaction T to a new value. A later rollback of transaction Ti, as a result of the 
update that occurred after T started, will not violate the atomicity rules since the 
rolled back values will reflect the updates made by update propagation transaction T. 

Noting the foregoing, to properly carry out the system and method of the 
present invention, it is necessary to enforce the atomicity equation 0((R u U) n U0<2 
by rolling bade all transactions Ti for OCCfU u Uj) n U)>1. In feet, this rolling back 
may be considered to apply to all transaction for which 0((R ul))n U)X). 

As discussed above, the update propagation is carried out, preferably, 
using four components. These components are source log processing, target log 
processing, update preprocessing, and update propagation to the target database. 
Briefly, as discussed previously, source log processing creates the update domain for 
the update propagation transaction; target log processing creates the update domain 
for the target transactions based on which transactions have to be rolled bade before 
the update transaction starts; update processing, which is the destaging from the cache 
memory all of the records in the update domain of the update propagation transaction 
and the rolling back of all pending target transactions that overlap the domain; and 
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update propagation to the target database. Each of these components will now be 
discussed in detaiL 

Source Log processing 

The source log processing component of the system arui method of the 
5 present invention will receive as its input parameter one log entry at a time. These log 
entnes apply to the source database, which in the system shown in Figure 1 would be 
marnframe control unit/database 104 that has l^n re^ te as DEL The source 
database is where the updates originate. The source database includes a source 
transaction update table that is referred to as SourceTransacUonUpdateTable, This 
10 table lists all of the Tj s update records and the new values for these records. The 
ProcessSourcel^g of the source database implements the 
SourceTransactiOnUpdateTablei. 

The ProcessSourceLog, as stated above, receives one input parameter Thelog 
entries consist of the intercepted data and the entries are input to the log one at a time 
The entries are datathat has been intercepted by, and visftle through^^ 
buffer 220 that is shown in Figure 2. Accordingly, common I/O buffer 220 will 
contanr the successive intercepted source log data that has been input to the system. 
That *, I/O buffer 220 will contain the next intercepted source log I/O data. This 
intercepted data will provide the SourceTrausactionUpdateTable, with the data it will 
20 form a list of tables for all of the open source transactions. The source log processing 
component will operate according to the following: 
ftocessSo 

^ iflObuffercontafesBTkthen 

if TOhJT* 5 T W t3 ? e S °™TransactionUpdateTable k 
it iObuffer contains and its value Vj then 

., TOK and its value Vj to SourceTransactionUpdateTable* 

lflObuffer contains ET k then ^ 

30 prTpaga^ TnmsactionU P da t^able i as ready for update 

if IObuffer contains AT k then/* is an abort transaction marker */ 
} clear and release SourceTransactionUpdateTable* 



35 



The results of the source log processing will be the listing of all of the 
transactions that will be available for use by the system components. 



source 
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Target Log Processing 

The second component is the target log processing component. This 
component is to track all of the pending target transactions that execute in parallel to 
the update propagation transaction. These log entries apply to the database which in 
5 the system shown in Figure 1 is open system database 108. This database has been 
previously referred to as DB2, the target database where the updates axe to propagate. 

The purpose of obtaining this target log information is to rollback all of the 
parallel target transactions Ti to the update propagation transaction T for which 0(Uj 
nU)>0. As stated previously, this may take place before transaction T has started 
10 executing. 

Similar to the source log processing component, the input parameter to the 
target log processing component will be one log entry at a time. These input 
parameters will be included in TargetTraiisactionUpdateTable^. The list will include Ti 
update records and their new values. 

15 The TargetTransactionUpdateTablei is implemented through the 

ProcessTargetLog that is part the target database. The input parameters axe received 
from the common I/O buffer 220 that is shown in Figure 2. That is, the entries are 
data that has been intercepted by, and visible through, common I/O buffer 220. 
Common I/O buffer 220 will contain the successive intercepted source log data that 

20 has been input to the system. This intercepted data will provide the Target 
TransactionUpdateTablei with the data it will form a list of tables of all open 
transactions. The target log processing component operates according to the 
following: 

ProcessTargetLogCIObufFer, TargetTransactionUpdateTable) 
25 { 

if IObufifer contains BT k then 

create new table TargetTransactionUpdateTablei 
if IObuffer contains rjjc and its value Vj then 

add q and its value Vj to TargetTransactionUpdateTablei 
30 if IObuffer contains ET k then 

clear and release TransactionUpdateTablei 
if IObuffer contains AT* then /* is an abort transaction marker */ 

clear and release SourceTransactionUpdateTablek 

} 

35 
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The results of the target log processing willbetbe HstiigofaDoftbe 
transactions that will be available for use by the system components in update 
propagation. 

Update Preprocessing 

The third component is the update preprocessing component This component, 
preferably, is executed before applying the update propagation transaction that may be 
in a SoureeTransactionUpdateTable,. When the update prepn^mg component is 
operated, preferably, two operations will take place. The first is that the cache 
containing the read information will be flashed to obtain this information. Next, the 
flashed cache locations wffl have those locafe 

of the records in the SourceTransactionUpdateTablek. The second is that there wffl be 
a rolling back of all open target transaction T, for those cases m which 0(Ui n U)>0. 

The update preprocessing component preferably has two hn^m parameters. 
These parameters are obtained from SourceTransactionUpdateTablek and 
TargetTransactionUpdateTable,, As discussed, SourceTransactionUpdateTable, will 
contain the list of records to be updated by update propagation transaction and 
TargetTransactionUpdateTable, will contain a list of target transactions that have not 
been committed to a transaction T. The operation of the update preprocessing 
component is as follows: 

UpdatePreprocessing (SourceTnuisactionUpdateTablev 
TargetTransactionUpdateTable) 

for each record m each TargetTransactionUpdateTables do 

If TargetTransactionT^pdateTablei n 

SourceTransactionUpdateTablek * 0 then Rollback 
Transaction(k) 

30 ^^^^^inSouiwTransactionUpdateTabletdo 

Map R, to the corresponding record r, 
Destage(ri) 

} 

The purpose of the update processing component is to prepare for updating the 
target database. This component has looked at the tables in the source and target logs 
and ensured that upon executing the update propagation to the target database there 
wdl not be any violation of the atomicity rules. Moreover, the update preprocessing 

14 
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c»mponent will also look to ensure that the reads from the target database do not 
violate these rules. 

Update Propagation 

The update propagation component's primary function is to propagate updates 
to the target database. This is accomplished by executing an update transaction T 
based on the values in a SourceTransactionUpdateTablei. When the update transaction 
T starts, it will cause a timer to be initiated after a predetennined number of X units 
have expired. When this timer expires, it wffl remove the particular 
SourceTransactionUpdateTablei &om the system. It will also be removed if the 
transaction is completed before the timer expires. The controlling event of the two 
wffl be the one that happens last. During the operation of the update propagation 
component, the system and method of the present mventfon wffl evahiate the intact 
of transaction Ton the atomicity of any other target transactions until the 
SourceTransactionUpdateTablei has been removed from the system. 

The update propagation component receives one parameter. This parameter is 
what is present in SourceTransactionUpdateTablej. These wffl be the lists or records 
to be updated and their corresponding update values. The update propagation 
component operates according to the following: 

20 UpdateDB(Sourc»TransactfonUpdateTableO 

set timer event inT time unites for a SourceTransactionUpdateTablei 
/*propagale updates 
Create new unique transaction id (k) 
25 Write BT k to the log 

for each mapped record n in SourceTransactionUpdateTablei do 

read 15 before-image value BVj 

write T ix and its before- image value BVj to the target log 
30 write value Vj to record n 

write rye and its value to the target log 

Write ET k to the log 

35 Once the update propagation process has been carried out, the target database 

wffl be update with the desired new information at the I/O stream without the need to 
use valuable CPU time or TCP/IP communications lines. 
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It is understood that in discussing the update process of the present invention 
that the database operations of rollback and flashing the cache may be programmed. It 
is also understood that the actions of rollback and flashing the cache are performed 
conventionally. 

5 ^ i< ^^^marMrnethodasdescrn^ 
the invention is carried out according to thefoHowing: 
UpdatePropagationO 

do forever 
10 { 

interest next read or write operation to lObuffer 
case(IObuffer) 

{ : 

write to source log database: 

/*add record to the right TransactionUpdateTable 
Pr^essSourceLogdObufjfer, SourceTransactionUpdateTable) 
Write record to source log /^forward write to destination 
If record is ETj then /*start update propagation transaction 
20 /*spun update propagation sequence to be executed as a 

separate task 

/♦parallel with intercepting reads and writes 

fork (UpdateDB(TransactionUpdateTablei) 
write record njkto target log: 

25 ^cc^Targetl^gaOb^iffer.Targert'ransactionUpdateTable) 

Write record to target log /*Forward write to oestination 
^wrnjcompromising transaction's consistency rollback the 

If rp, such that rj in SourceTransactionUpdateTable then 

30 

RoIlbackTransaction(k) 
clear TargetTransactionTable* 

read r from target database 
35 transaction breads compromise transaction's atomicity rollback 

if r such that r in some SourceTransactionUpdateTable then 
RoflBackRecord(r) 

}/*end case 
}/*end do forever 
40 Time event interrupt for transaction j: 

If SourcePendingTransactionTabiej not cleared yet and marked 
completed then 

Clear SourceTransactionUpdateTable! 
d - Endofupdate propagation transaction task for 

^ 3 Soun^TransactionUpdateTable,: 

if time event for SourceTransactionUpdateTablej occurred already then 
Clear SourceTransactionUpdateTablej Y 
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} 



else 

mark SourceTransactfonUpdateTablej as convicted 



5 In another embodiment of the system and method of the present invention, the 

updates will not only be written to the target database but they wffl be written in the 
source database log as a new transaction. This wffl peimitthetrackmgoftheirodate 
events for action at a later time, such a database reconstruction or recovering. 

The terms and expressions that are used herein are meant to be terms of 
10 expression and not limitation. And there is no intention in the use of such terms and 
expressions of excluding the equivalents of the features shown and described or 
portions thereon, it being recognized lhat varfous modification are po^ 
the scope of the present invention. 
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Claims: 

databases as such write and tw»h ;»„* n . . ' 

system . wnte and read inputs arc present in input/output ("I/O") streams of the 

(b) ^-P^tteintecceptedwri^ 
mputs that are for updating system databases; 
(CO ^"a^datab^^^ 
lead mputsthat are for updating the source database; 

read mputs that are for updating the source database; 

(e) writing to the source database the write and read inputs that are for 
updating the source database; and 

(f> writing to the target database the write and read inputs that are for 
updating the source database. 

2. The method as recited in claim 1 when-i,, ™»„ „ 

an VO buffer. 316 ^rcepted * 

3- The method as recited in elaim 2, wherein the intercepted write and read inputs 
are visible through the I/O buffer. a mputs 

1 « ** ^ ^ ^ whe -- the write and read inputs that are for 

updaturg the source database are input one at a time to the source database log 

5_ The method as recited in claim 1, wherein the write and read inputs that are for 

• The method as recited in claim 1, wherein the updates are written to the target 
databaseonanon-mterforfogb^^ 

L. Z ^"^" Cto6 ' Wb ^ Wten ^^^testothetarget 
update transaction will be rolled back to a nou-interfering time 
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8 . The method as recited in claim 1 , wherein the source database is operated 
according to first database software. 

9. The method as recited in claim 8, wherein the target database is operated 
according to second database software. 

10. A method for propagating cross-platform database updates for a system, 
comprising the steps of: 

(a) intercepting a write or read that is input to an Input/Output ("I/O") buffer, 
with the write or read being intended for updating a source database; 

(b) writing each write to a source database log and a target database log: 

(c) reading each read from the target databa^ and associating the read with a 
transaction listed in the source database fog and the target database log; 

(d) writing the updates from the source database log to the source database; 

and 

(e) writing tip updates from the target database log to the target database, 
according to timing that is free from interfering with other transactions affecting the 
target database. 

11. The method as recited in claim 1 0, wherein the intercepted writes and reads are 
visible through the I/O buffer. 

12. The method as recited in claim 10, wherein the writes and reads that are for 
updating the source database are input one at a time to the source database log. 

13. The method as recited in claim 10, wherein the writes and reads that are for 
updating the source database are input one at a time to the target database log. 

14. The method as recited in claim 10, wherein the source database is operated 
according to first database software. 

15. The method as recited in claim 14, wherein the target database is operated 
according to second database software. 

16. The method as recited in claim 10, wherein when writing the updates to the target 
database interferes with otter transactions affecting the target database, the writing 
update transaction will be rolled back to a non-interfering time. 

17. A system for propagating crpss-platfbrm database updates, comprising 
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a first platform that further includes, 

a ^*^,withthelirstd^ 
receiving update write and read information, and 

a first processor that connects to, and controls operation of the first 



-j • 

a second platform that further includes, 



a second database, with the second database mctading a second database 
tog for receiving update write and read information, and 

a second processor that connects to, and controls operation of the second 

database; and 

ahost that is disposed between the ^ processor and database and between the 
second processor and database, with the host further including, 

secnnHH.K " "° buffi * intercepts for writes and reads for updating the first and 
second databases, 

with ^ PrOCCSSOr ^ for ^ ^ ^ to the first and second databases, 

a non-mterfenng manner with other transactions affecting the second database. 

18. The system as recited in claim 17 wherein thr w ,w„k • 
to first database software. " 

19. The system as recited in clahn , 8 , wherein the second database is operated 
according to second database software. 
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